XEN a duże wykorzystanie CPU przez maszyny wirtualne

Wirtualizacja zawsze niesie za sobą przynajmniej częściowe wykorzystanie procesora na potrzeby nadzorcy. Przy niskim i umiarkowanym obciążeniu, wirtualne procesorz nie są zbyt często przełączane pomiędzy fizycznymi procesorami i ich rdzeniami, przez co obciążenie jest prawie identyczne, jak dla zlokalizowania wirtualnych maszyn na fizycznych urządzeniach. W przypadku dużego obciążenia procesora, różnice te są już znacznie bardziej widoczne, szczególnie gdy wykonywany jest ten sam proces (np. jest to webserver, na którym główne obciążenie generuje PHP).

W takim przypadku obciążenie przy wirtualizacji będzie dużo wyższe ze względu na potrzebe importowania do pamięci podręcznej procesora (cache L2, L3) samego PHP. Wynika to z częstego przełączania wirtualnego procesora pomiędzy rzeczywistymi procesorami, przez nadzorcę wirtualizacji. Każde takie przełączenie powoduje potrzebę załadowania do pamięci podręcznej procseora ponownie instrukcji niezbędnych danemu systemowi, używanych przy przetwarzaniu danych.

Rozwiązaniem tego problemu jest przypisanie do konkretnego fizycznego rdzenia procesora, wirtualnego procesora. W przypadku gdy suma wszystkich wirtualnych procesorów jest większa od ilości fizycznych rdzeni, należy to wykonać tylko dla najbardziej obciążonych serwerów. W przypadku XEN służy do tego komenda xm vcpu-pin <host> <vcpus> <cpus>. Przykłady jej użycia poniżej:

xm vcpu-set host 8
xm vcpu-set host2 8
xm vcpu-set host3 8
xm vcpu-pin host all 8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
xm vcpu-pin host2 all 0,1,2,3,4,5,6,7
xm vcpu-pin host3 all 8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31

W powyższym przykładzie deklarujemy dla obu hostów po 8 wirtualnych procesorów, a następnie przypisujemy host2 do jego wszystkich procesorów, 8 fizycznych procesorów. Pozostałe 2 serwery mogą korzystać ze wszystkich pozostałych procesorów.

Zmiana ilości wirtualnych procesorów dla hosta lub modyfikacja ilości maszyn wirtualnych na serwerze spowoduje zresetowanie ustawień przypisania procesorów do domyślnych wartości, czyli każdy wirtualny procesor ma przypisane wszystkie fizyczne procesory, czyli może być migrowany przez zarządzcę między nimi bez ograniczeń.

gsh czyli grupowe SSH

GSH (obecnie przemianowany na Polysh), ktorego nazwa pochodzi od Group Shell, to skrypt umozliwiajacy rownolegle polaczenie z dowolna (ograniczeniem sa tutaj mozliwosci systemu) iloscia serwerow poprzez SSH. Dzieki temu mozemy wykonac dowolne polecenie na wielu hostach naraz. Oczywiscie fani Bash'a zapytaja "ale w czym to lepsze od prostej petli for?":

for i in `db0{01...20}`; do uname -a; done; 

Chocby w tym, ze powyzszy skrypt bedzie wykonywal sie dla kazdego hostu po kolei. W przypadku malej liczby serwerow i szybko wykonujacego sie polecenia nie ma wiekszych problemow. Zaczynaja sie one, gdy mamy wiele (powiedzmy ponad 50) serwerow i skrypt ktory wykonuje sie kilkanascie/kilkadziesiat sekund. W takim przypadku docenimy mozliwosc rownoleglego wykonania tego polecenia na wszystkich hostach. Oczywiscie mozemy z pomoca bash'a wykonac to rownolegle, jednak naklad pracy jest zdecydowanie wiekszy. Do tego wykonanie tego samego polecenia za pomoca gsh jest duzo prostsze:

gsh db0"<01-20>" --command='uname -a' 
#lub
gsh db0"<01-20>"
Ready(20) > uname -a

Pierwszy przykład stosuje rzadko - praktycznie tylko gdy wynik dzialania skryptu na wielu hostach jest dodatkowo przetwarzany dalej (sort, wc, grep etc.). Drugi przyklad umozliwia nam dzialanie jak na zwyklej konsoli, z ta roznica ze polecenie jest wykonywane na wszystkich hostach jednoczesnie. W przypadku maszyn wirtualnych, na kotrych wywolanie danego polecenia/skryptu wywoluje duze obciazenie warto pamietac o zadbaniu by skrypt nie uruchamial sie w tym samym czasie na wszystkich wirtualkach:

sleep $(( $RANDOM%120));