Nvidia vGPU

Dawno nic nie napisałem. Brzydzę się sobą i samobiczuję na placu przed firmą. Nastał jednak ten dzień, kiedy w końcu poza wysyłaniem maili, spotykaniem się i jedzeniem 8 obiadów dziennie oraz nieprzerwaną telekonferencją, mogłem popracować. A temat zgłębiłem zaiste ciekawy!

Końcem lata wysypało projektów VDI-owych jak grzybów w lesie. Infrastruktura choć standardowa, to bardzo przyjemna – oranie przeszłości, czysty start, wszystko na świeżo jak majtki z 5ásec. Projekt ten miał jednak pewne wyzwanie, z którym jakiś czas się nie mierzyłem – karty graficzne Nvidia… a trochę się w nich zmieniło od K2.

Aby ustawić scenę opowiem trochę o przypadku, który realizowaliśmy. Klient miał 100 VM – wydaje się niewiele, zapięte one były na cienkich klientach. Dwa monitorki, sieć 1G. Wszystko zdaje się dosyć niewielkie i skromniutkie… Wtem! Każda z VDI miała umożliwiać w miarę sensowne korzystanie z oprogramowania zwanego ArcGIS produkowanego przez firmę ESRI. Generalnie służy on do pracy nad mapami w 2D/3D i umożliwia tworzenie, przetwarzanie istniejących map, analizę danych przestrzennych oraz ich wizualizację, oraz zarządzanie danymi w geobazach. A co z naszej architektonicznej perspektywy najistotniejsze, soft ten implikuje, że VDI potrzebuje całkiem sporo zasobów. Stąd pojawiły się w kadrze karty Nvidia serii… no właśnie, jak się okazało nie wiadomo jakiej.

Zacznijmy od tematu co jest w ogóle dostępne. Na dzień pisania tego artykułu mamy do wyboru:

Moim zdaniem zanim wgryzłem się w nowe modele i ich różnice, najbardziej koszerna zdawała się karta M10. Kusiły 4 GPU, sporo rdzeni robiących CUDA, dużo RAM i akuratne profile vGPU. Pojawia się jeszcze również karta M60, która modelem może sugerować, że jest lepsza, większa, nowsza itp. To jednak nie jest prawda, karta ta jest raczej wycofywana i już się na niej nie projektuje. Po szczegółowe, lśniące opisy każdej z kart odsyłam na stronę Nvidia, tam dowiecie się wszystkiego. Tymczasem wróćmy do wymiarowania i projektowania na tym sprzęcie.

Przede wszystkim trzeba zrozumieć parametr Frame Buffer, który przekłada się niejako vGPU Profiles. Wspomniany Frame Buffer to w uproszczeniu ilość RAM jakie ma posiadać karta graficzna dopięta do naszej VM. Sprawa przy tym parametrze ma się podobnie jak w przypadku zwykłego RAM. To znaczy wszyscy wiemy, że gdy kończy się normalny RAM w maszynie zaczyna ona wykorzystywać swap, czyli miejsce na dysku twardym. Podobnie jest z Frame Buffer *FB) czy też profilem vGPU, gdy się on przepełni wykorzystywany jest normalny RAM. Wszystko wówczas mocno zwalnia dlatego, że musi choćby dwa razy przejść przez PCI – fizyki się nie oszuka. Zatem trzeba dość dokładnie zbadać (najczęściej metodą prób i błędów) jaki poziom FB konsumuje nasz użytkownik w VM. Generalnie, jeżeli np. FB jest na poziomie ~700 MB to nie wybieramy profilu 0,5GB w karcie a np. 1GB+. Pojawia się oczywiście pytanie jak to określić. Nvidia ma to niestety jedną odpowiedź – zrobić PoC, a nie każdy ma taki komfort… Jednak, jeżeli np. robisz migrację ze starszej wersji np. K2 możesz na esx wydać komendę:

{root@ESXi1:~] nvidia-smi

Otrzymamy wówczas mniej więcej taki wynik:

Można tam zobaczyć w kolumnie Memory-Usage ile nasza VM konsumuje pamięci. Tutaj akurat jest pokazane w stanie spoczynku, warto natomiast badać to w momencie normalnego działania. To będzie dobrą podstawą do dalszego wymiarowania.

Wróćmy do naszego scenariusza, przejęliśmy, że VM będzie używała profilu 1GB. Gdzieś tam w trakcie rozmów doszliśmy do wniosku, że chcemy upakować jak najwięcej VM na hoście – więc wybór padł na kartę M10 oraz ewentualnie T4, ale z większym naciskiem na M10, ponieważ ma więcej pamięci, co przekłada się na więcej użytkowników per serwer.

Myślę, że warto tutaj dotknąć tematu wymiarowania samego serwera. Temat bowiem nie jest trywialny. Zacznijmy od tego, że aplikacje 3D są wciąż (co zaskakuje) jednowątkowe, zatem lepiej się zachowują w środowisku z większą częstotliwością CPU niż ilością Core. Zatem trzeba iść w procki z serii np. Intel Gold+ to znaczy przykładowo w modele 6254 (3,1 Ghz, 18 Core), Gold 6246 (3.3 GHz, 12 Core), Gold 6244 (3,6Ghz, 8 Core), Gold 5217 (3GHz, 8 Core). Dlaczego się tak dzieje? Otóż wysoka częstotliwość proca może nas obronić przed tzw. CPU bottleneck, czyli w uproszczeniu ujmując sytuacją, gdy karta graficzna ma jeszcze moc, a procek już się zapchał. To jedna rzecz, druga to założenie maksymalnie 4 vCPU per jeden pCPU czyli fizyczny core/procek. Dodatkowo w kartach nowszych niż K2 mamy do dyspozycji technologię NVENC która optymalizuje/offloaduje operacje i możemy uzyskać około 25% wydajności procka. Rekomendowana ilość vCPU per VM przez Nvidię wynosi 4vCPU per 1pCPU. Zatem szybka kalkulacja:

2 x 3,3 GHz z 12 Core = 24 pCPU = 24 VM per host, przy założeniu over-subskrybcji 4:1 + 25% z NVENC to daje nam 30 VM z jednego serwera.

Na początku polityka… czyli co potrzebujemy, a co musimy kupić. Potrzebujemy karty, to oczywiste i tak było z kartami K2. Dawno, dawno temu, za górami, za lasami, gdy chciałeś mieć GPU to kupowałeś, wkładałeś i wio. Niestety te czasy dawno minęły, teraz musisz jeszcze kupić licencję – per VM, na rok lub na zawsze z minimum rocznym suportem. Licencji jest klika:

Na początku myślałem, że styknie nam vPC. Miała wszystko – czarne włosy, brązowe oczy… po prostu piękna. Jakiż był mój zawód, gdy okazało się, że jasne, działać będzie, ale nie jest certyfikowana w setup, który chcemy zbudować (ArcGIS ty draniu!). Musimy iść w Quadro (QvDWS) – oczywiście drożej, ale ponoć optymalnie i cudownie. Nic to jak chce się być zgodnym, to trzeba zapłakać gorzko i płacić.

Zatem wiemy już, że trzeba będzie dużo MHz, licencję Quadro vDWS. To teraz pytanie, która karta, bo dalej pasuje nam M10 lub T4. Tutaj również, dzięki dobroci Nvidii przychodzi dokument https://www.nvidia.com/content/dam/en-zz/Solutions/design-visualization/solutions/resources/documents1/nvidia_quadro_vdws_app_sizing_guide_for_esri_final.pdf gdzie! T4 jest tylko certyfikowana pod ArcGIS. Hehehe, nie da się tego lepiej rozegrać. Zatem zestaw gotowy – T4 wysunęło się na prowadzenie. Nvidia poleca używać profilu T2-Q2, dzięki czemu jedna karta dowozi 8 sesji. Zdecydowaliśmy się na serwery HPE DL380 Gen 10 maksymalnie, można w nie wsadzić max 5 kart:

5 x 8 daje nam 40 sesji VDI per serwer. Jednak zwrócimy uwagę, że wyliczyliśmy, iż procek ogarnie max 30 VM per serwer. Pójdziemy zatem w odrobinę bardziej wytworne procesory, czyli np. Intel Xeon Gold 6154 3,0 GHZ na 18 rdzeniach. To daje nam:

2 x 3,0 GHz z 18 Core = 24 pCPU = 36 VM per host, przy założeniu over-subskrybcji 4:1 + 25% z NVENC to daje nam 45 VM z jednego serwera. Czyli sumując wszystko razem na 100 równolegle działających VDI z ArcGIS potrzebujemy 3 serwerów wyposażonych w procki np. Intel Xeon Gold 6154 3,0 GHZ na 18 rdzeniach, 512 GB RAM wyposażonych w 5 kart T4 każdy. Można się skusić nawet na 4 takie maszynki, jeżeli potrzebujemy wykonać prace serwisowe w czasie działania infrastruktury… ale to w naszym przypadku wydaje się zbytkiem łaski.