Donnerstag Feb 26, 2009

LDoms und Container auf der Schacholympiade

"Brauchen .... 1.000.000  gleichzeitig gehaltene TCP Verbindungen" war die erste aber nicht letzte interessante Information bei der Unterstützung der Schacholympiade in Dresden.  Die Zahl basiert auf dem Ansturm von geschaetzten 1 Million gleichzeitiger "Zuschauer". Um diesen Zahlen  weltweit gewachsen zu sein, hat Sun den Veranstaltern der Schacholympiade 2008 in Dresden zwei T5240 zur Verfuegung gestellt.  Damit wurde der gesamt Webverkehr bedient, der durch die Liveuebertragung der Partien ueber das Internet entstand.  Es war die erste Schacholympiade, die vollstaendig live im Internet uebertragen wurde. 


Derartige Schätzunge basieren zumeist ersteinmal auf reinen Annahmen zur Anzahl von Benutzern. Im Falle der Schacholympiade war der Wert bestimmt nicht zu Tief angesetzt, da ein stabieler und performanter Auftritt auch entsprechend mit "headroom" geplant werden will. Nun lässt sich nicht immer direkt von der Anzahl der Benutzer auf die gleichzeitig gehaltenen TCP-Verbindungen schliessen, in dem vorliegenden Fall war allerdings die Anwendung welche die Darstellung bei den Zuschauern übernimmt entsprechend hinsichtlich des Netzwerkverkehrs optimiert. Zudem spielt auch noch die Antwortszeit auf einen Request eine signifikante Rolle, dazu aber später. 


Technisch ist das Hauptproblem bei einem solchen Webauftritt die Anzahl der gleichzeitig zu haltenden TCP-Verbindungen.  Ein einzelner TCP-Stack kann zwar rein theoretisch eine fast unbegrenzte Anzahl an eingehenden Verbindungen gleichzeitig halten, allerdings wird die Verwaltung der Sessions als auch der einzelnen Verbindungen zunehmend aufwändiger und damit langsamer. Je langsamer der Zugriff auf die einzelnen Sessiondaten, desto länger braucht der einzelne HTTP-Request innerhalb der TCP-Verbindung, desto mehr TCP-Sessions stehen am System an, desto.... will man mehr, benoetigt man mehrere TCP-Stacks (siehe auch die Warteschlangentheorie) .  Um hier Abhilfe zu schaffen bleibt eigentlich nur übrig, den Clients mehr TCP-Stacks zur Verfügung zu stellen. Das wird in solchen Faellen z.B. durch Reverse-Proxies erledigt, die dem eigentlichen Webserver vorgeschaltet werden.  Es könnten auch mehrere Web-Server zum Einsatz kommen, allerdings haben die Proxies diverse andere Vorteile wie z.B. die Verwaltung von grösseren Content-Caches als es dem normalen Web-Server möglich ist.


Um ausreichend viele solcher Proxies konfigurieren zu koennen, wurden die beiden T5240 mit je einer LDom mit 12 Cores konfiguriert.  In diesen beiden LDoms liefen jeweils 9 Solaris Container mit dedicated IP Stacks, womit dann ausreichend viele IP Stacks verfuegbar waren.  Die notwendigen Netzwerkverbindungen wurden ueber das "interne" Netzwerk der LDoms geliefert - extern waren pro Server eine 10GBit Ethernetverbindung im Einsatz.  Insgesamt sah die Konfiguration einer der beiden T5240 also so aus:



  • Eingesetzte Software:


    • JES Proxie- und Webserver

    • Solaris 10

    • ZFS

    • LDoms 1.0.3


Mit dieser Archtiktur wurde im Laufe der Veranstaltung einiges geleistet:


  • 960 Millionen Requests in 1.5 Wochen

  • 500000 eindeutig identifizierbare Hosts

  • Zusaetzlich natuerlich viele Zugriffe ueber die Proxies der grossen ISPs

  • Peak Leistung:


    • 11000 neue TCP-Sessions pro Sekunde

    • 200000 gehaltene Verbindungen

    • mittlere Antwortzeit 20ms


  • Hier noch ein Schnappschuss der Routerstatistiken von der Turnierwoche:


Die Auslastung der Server war dabei moderat:



  • Proxies: 15%  (96 Strands)

  • Service Domains: 6% (32 Strands)


Die erfreulich geringen Antwortzeiten waren ein direkter Erfolg der Gesamtarchitektur.  Die JES Proxie-Server hielten ihren Cache in einem ZFS Filesystem der LDom.  Der ARC des ZFS hatte nach einer gewissen Anwaermphase fast den gesamten Content gecached, so dass ein Grossteil der Anfragen direkt aus dem RAM der Server beantwortet werden konnte - es wurde also Antwortzeit durch RAM "gekauft".  Damit wurde es moeglich, die Anzahl der zu haltenden Verbindungen deutlich unter dem vorab geschaetzen Wert von 1 Million Sessions zu halten.


Ein sich ankuendigender Engpass war die Last auf dem einen VSwitch, der die Container mit virtuellen Netzwerkanschluessen versorgte und den gesamten Netzwerkverkehr bewaeltigen musste.  Hier konnte auf dem einzelnen Strand eine Auslastung von bis zu 80% beobachtet werden.  Waere die Last weiter gestiegen, haette die Konfiguration eines zweiten VSwitches und die Verteilung der vnet Ports auf beide VSwitches natuerlich schnell Abhilfe geschaffen.


Die Veranstalter waren nach Abschluss des Turniers hoch zufrieden mit der Leistung der Maschinen, die einen fluessigen und stabilen Webauftritt lieferten.  Dass dieser Webauftritt mit nur 2 Servern in insg. 4 Hoeheneinheiten realisiert werden konnte zeigt sehr anschaulich, wie effizient man mit Solaris, Containern, LDoms und ein wenig CMT-Hardware einen leistungsfaehigen Webauftritt realisieren kann.

About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute