Benchmarki VM c.d

Tym razem hostem jest laptop z procesorem AMD Athlon X2 QL-60, 2GB pamięci RAM, grafiką GeForce 9100M G a testowym systemem jest 64-bitowy Windows Server 2008 EE. Dla działającego realnie Windowsa zostały zmierzone wyniki PCMark05 w trybie oszczędzania energii (obniżenie do połowy taktowania CPU, spowolnienie grafiki itd.) i w trybie wydajności -obydwa testy wykonywane na jednym rdzeniu CPU (żeby można było porównywać wyniki maszyn wirtualnych, które raczej mają jeden VCPU) i tryb wydajności na obu rdzeniach.
V100 to VMWare Server 2.0 + 1 VCPU + W2K8 768MB RAM, V200 to ta sama konfiguracja ale na dwóch wirtualnych procesorach. VB to VirtualBox 2.1.
VM2 i VB2 to VMWare i VirtualBox z W2K8 na 1 CPU i zmniejszoną pamięcią do 512MB. Oprogramowanie do wirtualizacji było w 64-bitowych wersjach, zainstalowane na OpenSUSE 11.1 64-bit, jedna partycja / na XFS-ie.









Jakie z tego wnioski?

• Cache'owanie systemu plików w Linuksie i Windowsie 2008 (wow) jest ładnie zrobione i jak jedno zgra się z drugim to mamy system wirtualny szybszy od rzeczywistego
• VirtualBox gdyby miał dobre narzędzia do zarządzania mógłby być produktem serwerowym
• Nie ma sensu wybierać Xen-a, bo wirtualizacja z patchowaniem strumienia instrukcji jest szybsza
• Zamiast VMotion można zrobić wirtualizację usług, jeśli mamy do czynienia z WebService'ami to wystarczy Apache 2.2.10 i mod_proxy_balancer
• Powinienem na Oracle'u 11 wystawić jako WebService'y jakieś operacje w schemacie hr i wtedy można by mieć jakieś sensowne życiowe testy

Jeśli wyeliminujemy wyniki grafiki 2D to można przyjąć, że mamy 20% spadku wydajności. Ale... 20% per CPU. Jeśli na kilkurdzeniowym serwerze mamy uruchomioną maszynę z jednym wirtualnym procesorem to... patrz przypadek 'AVG Performance 2CPU'. Powiedzmy, że ten spadek wydajności rekompensujemy sobie stawiając równolegle pare maszyn, usługa w nich uruchomiona moze być balansowana - czy teraz też będziemy mieć 20% per CPU? Pewnie więcej...

Prawie się zakochałem...

• Ideał dziewczyny ma tytuł magistra inżyniera z informatyki na EiTI PW


• Napisała, i to pod Windowsem, i to bardzo ładnym kodem (wszystkie formatowanie perfect, czyta się jak książkę Clancy'ego), kawałek softu sprawdzający, czy działamy węwnątrz sprzętowo akcelerowanej maszyny wirtualnej. Robi się to tak, przy wyłączonych przerwaniach: (1) czyszczenie TLB (czyli przeładowanie rejestru CR3), (2) sprawdzenie za pomocą źródła czasu TSC i operacji dostępu do pamięci, ile cykli robi procesor przy istniejącym mapowaniu adresu wirtualnego na fizyczny, (3) sprawdzenie tego samego ze wsadzeniem po środku instrukcji vmexit. Jeśli jesteśmy wewnątrz maszyny wirtualnej instrukcja wyjścia z niej spowoduje wywołanie handlera po stronie nadzorcy maszyny wirtualnej i zanim wrócimy minie sporo cykli procka. Czyli czas(3) - czas(2) będzie większy od zera.


• Napisała rootkita, który obchodzi w/w detektor...
  

Gdyby jeszcze nie paliła... (nie wiem czy pali). Fajnie się ubierała na niektórych konferencjach - na czarno-biało, tak w stylu profesjonalnej hackerki.

Wracając do badań Pani Rutkowskiej, można napisać takiego rootkita, który wsadzi działający system operacyjny do maszyny wirtualnej (w locie, odpalamy rootkita i ziuum, a nawet szybciej) i z wnętrza maszyny wirtualnej nie będzie można tego wykryć. Matrix. System działa w wirtualnym świecie i nic o tym nie wie. I nie przyjdzie do niego żadna Trinity od firmy Symantec i nie powie, że to co widzi to ułuda.

Swoją drogą, czy ścigający się AMD i Intel, tworząc sprzętową wirtualizację pomyśleli o bezpieczeństwie, czy nie mieli czasu? Nie twierdzę, że HVM jest złe, bo sam na 32-bitowym Gentoo miałem 64-bitowego Solarisa, ale przy takim komercyjnym wyścigu dużych graczy o kasę*, może ktoś zapomniał zastanowić się nad bezpieczeństwem.

*technologię wirtualizacji ma EMC/VMware, Citrix, Oracle, Novell, RedHat, Sun i Microsoft (z tym, że to coś Microsoftu w wersji beta umie tylko "coś tam, coś tam" i po instalacji na moim laptopie z Athlonem X2 QL-60 blokuje sprzętową wirtualizację totalnie tak, że narzędzie od AMD mówi, że jej nie ma).

hpscan.tgz

Dzisiaj musiałem zeskanować siebie z dowodu. Mam w domu skaner HP 3530c, który jest obsługiwany przez kookę (której nie ma na Fedorze 10, ale jest na OpenSUSE 11.1) - niestety zeskanowane obrazki mają dziwnie podbitą korekcję gamma (są za jasne). Wygooglałem hpscan.tgz, rozpakowałem, pod GCC 4.3 się nie chciało skompilować, ale całe szczęscie w pakiecie była binarka. Binarka wymaga dostępu do pliku urządzenia - najprościej odpalić ją jako root. Udało się: 'Please wait, warming up...', brrrrm, brrrm, iyyyyy, 'head is returning' i mam obrazek w formacie PPM. Z tym hpscan.tgz to było tak, że dawno temu kiedy byłem piękny i młody miałem sobie kupić na imieniny skaner HP. Ale kupiłem takiej jednej Ance pierścionek i odłożyłem zakup skanera na następne imieniny. Niestety w następnym roku pojawiła się nowa seria skanerów HP niekompatybilna z Linuksem, a starych już nie było. Kupując HP 3530c byłem święcie przekonany, że skaner będzie działał mi z Linuksem (w 2001 roku chyba używałem już Gentoo). A okazało się, że no way i w wakacje męczyłem się nad programem w C, którym mógłbym coś wydobyć ze skanera. Sterowanie ruchem głowicy trochę jest do kitu (odgłosy są straszne), ale generalnie program działa. Dzisiaj Anka jest prawdpodobnie gruba i brzydka (a na pewno nosi okulary), a skaner HP 3530c nadal wygląda (po starciu kurzu) jak nowy.

Prosty skrypt do przyrostowego monitorowania logów

#!/bin/sh
function check_log() {
  logfile="$1"
  pattern="$2"
  if [[ -z $pattern ]] ; then
      echo "Wzorzec do wyszukiwania nie moze byc pusty"
      return 1
  fi
  if [[ -f $logfile ]] ; then
      size=`LC_ALL=C stat ${logfile} | grep Size | cut -d" " -f4 2>/dev/null`
      old_size=`cat $logfile.size 2>/dev/null`
      diff=`expr $size - $old_size 2>/dev/null`
      if [[ -z $diff ]] ; then
          diff=$size
      fi
      if [[ $diff -lt 0 ]] ; then
          diff=$size
      fi
      if [[ $diff -gt 0 ]] ; then
          echo "Plik zmodyfikowany, roznica $diff bajtow"
          tail -c $diff $logfile | grep -A 20 -B 5 -e "${pattern}" 2>/dev/null 1> $logfile.err
          cat $logfile.err
      else
          echo "Plik bez zmian, rozmiar $size"
      fi

      echo "$size" > $logfile.size
  else
      echo "Nie ma takiego pliku $logfile"
  fi
}

logfile="/home/weblogic/bea/domains/WebPortal/servers/WebPortalServer1/logs/WebPortalServer1.out"
pattern="Exception"
check_log $logfile $pattern

Intel Core i7 i TLB

Translacja adresów wirtualnych na fizyczne jest w x86 tak zrobiona, że mamy drzewiastą strukturę tablic stron (jedna tabelka na najwyższym poziomie z elementami wskazującymi na tabelkę na drugim poziomie, a elementy w tabelce drugiego poziomu wskazują na tabelkę trzeciego poziomu, ..., w tablicy czwartego poziomu mamy odowołania do fizycznych ramek pamięci).
Pierwsza cześć adresu wirtualnego (ileś tam bitów) stanowi indeks dla pierwszej tabelki, druga część dla drugiej tabelki itd. Trick jest taki, że element w tabelce pierwszego poziomu może wskazywać na swoją tabelkę, i taka referencja do własnej tabelki może zajść 3 razy pod rząd.
Procesor bierze adres wirtualny, przechodzi po drzewku i na końcu uzyskuje adres fizyczny.
Takie chodzenie jest kosztowne dlatego pary [adres wirtualny, adres fizyczny] są cache'owane w buforze TLB. W Core i7 TLB ma cache dwupoziomowy: level 1 - 64 pozycje, level 2 - 512 pozycji, takiego dużego TLB procesory jeszcze nie miały - powinno to dać dużego kopa (i daje, co widać w benchmarkach).
Manual Intela mówi, że jeżeli ta sama fizyczna ramka pamięci jest używana w N mapowaniach, to wyczyszczenie cache'u TLB dla tej ramki powinno być wykonane N razy, czyli N razy musi być wykonana instrukcja INVLPG. Jeśli za mało razy zawołamy INVLPG, to procesor pamięta złe mapowanie i coś złego się stanie, bo użyje złego adresu pamięci fizycznej, w najlepszym przypadku BSOD. Manual mówi też, że jeśli są robione tricki z wskazywaniem elementu tablicy na swoją własną tablicę M razy, to INVLPG musi być zawołane M-1 razy. A wszyscy myśleli, że INVLPG działa raz a dobrze...

Balancer, failover i wdrożenia zero-downtime

#################################
# INSTANCJA 443
#################################
<VirtualHost _default_:443>
ServerRoot "/etc/httpd"
ProxyPass /svc balancer://svcCluster443 stickysession=JSESSIONID

<Proxy balancer://svcCluster443>
BalancerMember http://10.70.10.2:8080/svc route=instance0 loadfactor=99
BalancerMember http://10.70.10.3:8080/svc route=instance1 loadfactor=1
BalancerMember http://localhost/maintenance route=maintenance loadfactor=1 status=+H
</Proxy>

<Location /balancer-manager>
Order Deny,Allow
Deny from all
Allow from 192.168.2.33
SetHandler balancer-manager
</Location>

</VirtualHost>


Apache 2.2.10 ma bardzo fajnego wbudowanego balancera. Załóżmy, że serwowana przez nas usługa ma być uaktualniona. Zestawiamy całe środowisko na instance1 i za pomocą balance managera zmieniamy wagi instance0 i instance1 - bieżące operacje zostaną dokończone na aktywnej instancji 0, a nowe będą wykonane przez instancję 1. Całkowicie transparentnie dla użytkownika końcowego. Żeby przełączanie działało tak jak chcemy musimy tylko wyedytować plik źródłowy httpd-2.2.10/modules/proxy/mod_proxy.c i zmienić ograniczenia na lbfactor (np. na zakres 1-1000000). Apache'a konfigurujemy następująco:

./configure --prefix=/usr/local/apache_balancer --enable-static-support --enable-mods-shared=all --enable-deflate=shared --enable-logio=shared --enable-mime-magic=shared --enable-expires=shared --enable-headers=shared --enable-usertrack=shared --enable-proxy=shared --enable-proxy-connect=shared --enable-proxy-ftp=shared --enable-proxy-http=shared --enable-proxy-balancer=shared --enable-ssl=shared --enable-http --enable-rewrite=shared

Gdyby usługa na instance0 zespuła się możemy zaserwować statyczną odpowiedź o awarii serwisu, służy do tego route=maintenance ze statusem ustawionym na +H (hot standby).
Hot standby nie działa na RedHacie 5.1/5.2 i SLES 10 SP2, które mają starszego Apache'a.