Der Aufbau hochskalierbarer Serverfarmen

Der Aufbau hochskalierbarer Serverfarmen
Einleitung
Zur Anpassung an den ständig
steigenden Site-Verkehr und
einer damit gekoppelten
Leistungssteigerung muss eine
wohl durchdachte und
entsprechend aufgebaute
Serverfarm leicht und
kostengünstig erweiterbar, also
skalierbar sein. Mit der
Commerce Edition von Site
Server 3.0 (SSCE 3.0) steht
Ihnen zum Aufbau einer
ökonomisch vertretbaren,
hochskalierbaren Serverfarm
genau das richtige Werkzeug zur
Verfügung. In diesem Beitrag
erfahren Sie, wie man eine
Serverfarm auf ein
Durchsatzvolumen von 100000+
gleichzeitig zugreifenden
Benutzern skaliert und dazu nur
ein notwendiges Minimum an
Servern einsetzt.
Eine leistungsstarke,
hochskalierbare Serverfarm
besteht aus wenigen
konsolidierten Webservern, die
leichter zu verwalten sind als
unkonsolidierte. Mit Hilfe
moderner Verwaltungssoftware
wie z.B. HP OpenView oder CA
Unicenter TNG lassen sich
Komplexität und
Verwaltungskosten merklich
reduzieren.
In der Tabelle werden die
verschiedenen Verfahren zum
Aufbau einer hochskalierbaren
Site beschrieben:
Vertikale HardwareSkalierbarkeit
Verbessern des Durchsatzes
durch verschärfte HardwareSpezifikationen unter
Beibehaltung der physikalischen
Anordnung sowie der Anzahl der
Server einer Serverfarm. Die
Horizontale HardwareSkalierbarkeit
Verbesserung der
Systemarchitektur
Durch Einsatz der beschriebenen
Skalierungsverfahren sind
Serverfarmen in einer
Größenordnung möglich, die die
vertikale Hardwareskalierung
vereinfacht zwar das SiteManagement, verursacht jedoch
höhere Hardwarekosten als eine
horizontale Skalierung oder eine
Verbesserung der
Softwarearchitektur. Und
dennoch muss bei Erreichen der
Maximalwerte die vorhandene
Hardware auf horizontale
Skalierung umgestellt werden.
Verbesserte Leistung durch
Hinzufügen von zusätzlichen
Servern. Die horizontale
Skalierung ermöglicht eine
hardwareseitige
Kapazitätserhöhung bei
niedrigeren Kosten; Wird der
Aufwand für die Site-Verwaltung
jedoch zu groß, muss auf die
vertikale Skalierung umgestellt
werden.
Man verbessert den
Serverdurchsatz bereits durch
das Aufspüren von Operationen
mit gleichen oder ähnlichen
Belastungsfaktoren und verteilt
die einzelnen Operationen auf
eine entsprechende Anzahl von
Servern. Die Methode der
Serverzuteilung an Operationen
mit gleicher, statt gemischter
Belastung ist wesentlich
effizienter und erhöht die
Kapazität um ein Vielfaches.
Verbesserungen an der
Systemarchitektur sollten daher
zu einem möglichst frühen
Zeitpunkt in der Projektplanung
berücksichtigt und implementiert
werden. Der Aufbau und Betrieb
einer Site mit effizienter
Architektur verursacht geringere
Kosten.
ursprünglich vorgesehenen
Designgrenzen weit übertreffen.
Vertikale Hardwareskalierung
Aktuelle Server haben
heutzutage soviel Hauptspeicher,
dass man darin fast den
gesamten Inhalt einer Site in den
Cache nehmen kann. Wird der
NTFS-Dateicache auf einer
schnellen Festplatte verwendet,
sind beachtliche I/ODurchsatzraten zu erzielen. Die
höchsten Steigerungsraten
werden jedoch gewöhnlich durch
den Symmetrischen
Mehrprozessorbetrieb (SMP)
erreicht. Dabei wird in der Regel
ein einzelner Server mit
zusätzlichen Prozessoren,
Speicher, Festplatten und
Netzwerkkarten ausgestattet. Für
eine vertikale Skalierung von
SSCE 3.0 stehen daher mehr als
genug Ressourcen zur
Verfügung.
Die Leistung von SSCE 3.0 ist
ziemlich CPU-orientiert, was auch
von Microsoft durchgeführte
Geschwindigkeits- und
Durchsatzbenchmarks
bestätigten. Durch die
"Geschwindigkeitsbremse" der
rechenintensiven ASPSeitenverarbeitung, wird die CPU
stark belastet. An der "VulkanKaffee"-Beispielssite (wird mit
SSCE 3.0 mitgeliefert) mit einem
Einzelprozessorsystem (Pentium
Pro, 200 MHz) ergibt sich ein
Durchsatz von 400
Benutzerzugriffen. Die
Konfiguration entsprach dem im
Dokument beschriebenen
"Durchsatz und
Leistungsanalyse" des Microsoft
Site Server 3.0 Commerce
Server (zu finden auf dem Site
Server 3.0 Commerce Edition
Resource Kit) und deren
angegebenen Spezifikation.
Vertikale Skalierung von SSCE
3.0 erfolgt durch die Erhöhung
der
Verarbeitungsgeschwindigkeit
und wird gewöhnlich mit einem
schnelleren Prozessor (z. B. ein
Pentium II, Pentium III und
deren Xeon-Ableger mit
vergrößertem Level 2-Cache)
erreicht. Zusätzlich können Sie
SSCE 3.0 auf einer mit jeder
UNIX-Hardwareplattform
vergleichbaren Compaq/Digital
Alpha-Hardwareplattform oder
auf Servern mit 64 Prozessoren
von Data General oder Unisys
ausführen. Als kleiner
Nebeneffekt kann ein Server
einen höheren Siteverkehr
verarbeiten.
Eine weitere Möglichkeit der
vertikalen Skalierung von SSCE
3.0 ist der Einsatz von Windows
NT 4.0 Server auf SMP-Servern
mit vier Prozessoren. Beachten
Sie jedoch in diesem Fall, dass es
beim Einsatz von SSCE 3.0 auf
Hardware-Systemen mit zwei
oder mehr Prozessoren zu
Performanceeinbrüchen kommen
kann. Obwohl der
Aggregatsdurchsatz höher ist,
steigen jedoch auch die
Investitionskosten
überproportional (der Per
Prozessor-Durchsatz ist bei SMPSystemen mit vier Prozessoren
niedriger als bei 2-ProzessorSystemen).
Generell geben wir folgende Empfehlung:


Verwenden Sie
bis zu vier
Prozessoren in
einem SMPSystem mit
horizontalen
oder
architekturalen
Skalierungsver
fahren.
Verwenden Sie
einen
möglichst
großen
Hauptspeicher,
das verbessert
den I/ODurchsatz des
IIS/ASPServerspeicher
s mit
kompiliertem
Skript,
einschließlich
der NTFSFestplattencac
he-Puffer.
 Vergrößern Sie
den Durchsatz
durch
Hinzufügen
mehrerer
SCSIPlattencontroll
er zur
besseren
Datenverteilun
g.
 Verwenden Sie
zusätzliche 100
mbsNetzwerkkarte
n zur Erhöhung
des
Netzwerkdurch
satzes.
 Eine ATMVerbindung mit
optischen
Glasfaserkabel
n ist zwar
relativ teuer,
aber dennoch
sehr
empfehlenswer
t.
Das Diagramm zeigt die
Erweiterung eines 1-Prozessor
(Pentium II)-Servers auf zwei
Pentium III Xeon-CPUs und
weiter auf einen Server mit 14
Alpha 21264Hochleistungsprozessoren.
Abbildung 1: Vertikale Hardwareskalierung
Horizontale Hardwareskalierung
Die horizontale
Hardwareerweiterung erhöht die
Leistung durch Hinzufügen von
SSCE 3.0-Servern zur
Serverfarm. SSCE 3.0Komponenten können über
mehrere Server hinweg
ausgeführt oder verteilt werden.
Durch diese Umverteilung wird
die Leistung erhöht.
Erweitern Sie Ihre Serverfarm
horizontal, muss die Last
gleichmäßig auf mehrere Server
verteilt werden, wozu es
geeignete Verfahren in Form von
Software wie Windows Load
Balancing Services (WLBS,
Betriebssystem-Software), DNS
Round Robin (NetzwerkSoftware) und Hardware wie
Cisco LocalDirector
(Netzwerk/Router) gibt. Vorzüge
der Lastverteilung sind die
Bereitstellung redundanter
Dienste, sowie eine erhöhte
Aggregatskapazität durch das
gezielte Verteilen der Last auf
mehrere Server.
In der Standardeinstellung
erstellt der SSCE 3.0-Site Builder
Wizard lastverteilungsfreundliche
Sites durch Vergabe von URL
oder Kunden-IDs auf CookieBasis. Der Assistent erstellt auch
Sites mit einer Sitzungs (engl.
Session)-/Statusverwaltung, die
sich zentral, jedoch abgetrennt
von den ASP-Servern in der
Commerce-Geschäftsdatenbank
befindet. Damit werden
Benutzeranfragen vom Load
Balancer zu jeder Zeit an jeden
verfügbaren Server adressiert,
ohne dass die Session oder der
Status des Benutzers verloren
gehen. Der Vorteil daran ist, dass
ohne Sitzungsvariable keine
Ressourcen für die Verwaltung
der Anwendersitzungen
verwendet werden.
Hinweis: Um Hardware effektiv
horizontal zu skalieren, sollten
Sie keine IIS-Sitzungsvariablen
verwenden und das IIS-SessionManagement abschalten.
Alternativ benutzen Sie die
Dynamic Data-Features des
SSCE 3.0 LDAP-Dienstes.
In Fällen, in denen eine
Anwendung mit der IISSitzungsverwaltung kodiert ist,
verwenden Sie den Cisco
LocalDirector-Router zur
Lastverteilung. Der Cisco
LocalDirector wird so
konfiguriert, dass sich jeglicher
Verkehr an der Client-/Quell-IPAdresse orientiert und der Client
bei jeder Anfrage an den gleichen
Ursprungsserver
zurückverwiesen wird. Dies
ergibt den gewünschten Effekt
der Lastverteilung. Die
Sessionvariablen befinden sich
lokal auf jedem Server; der
Client sieht den korrekten Satz
der Variablen samt Status.
Achtung: Das Anwenden dieses
Verfahrens kann bei bestimmten
Proxyserverfarmen zu Problemen
führen. Weitere Informationen zu
diesem Thema erhalten Sie im
Abschnitt "Abschalten der IISSessionverwaltung und Entfernen
der Session-Variablen".
Folgende Komponenten einer
SSCE 3.0-Serverfarm lassen sich
horizontal skalieren:
HTML/ASP-Server
LDAP-Server
Setzen Sie zusätzliche Server als
ASP-Server ein. Extern versehen
Sie die Server mit einem
gemeinsamen Domänennamen
und einer virtuellen IP-Adresse,
die einem Load BalancingSystem zugeordnet ist. Dieses
leitet den Verkehr an
verschiedene Server weiter. In
der Regel leitet die
Lastverteilung eineTCPVerbindung (z. B. eine HTTPAnfrage) an einen speziellen
Server und lässt diese
Serverleitung bis zur Beendigung
der TCP-Session bestehen.
Setzen Sie zusätzliche Server als
LDAP-Server ein. Extern
versehen Sie die Server mit
einem gemeinsamen
Domänennamen und einer
virtuellen IP-Adresse, die einem
Load Balancing-System
zugeordnet ist. Die ASP-ServerPersonalisierungs- und
Membership-Verzeichnis
Commerce-Shop
Das Diagramm verdeutlicht den
horizontalen Skalierungsprozess.
Folgende Server werden
Mitgliedschaftsinstanzen
verweisen auf den gemeinsamen
Domänennamen. Das Load
Balancing-System verzweigt den
Verkehr auf mehrere Server. In
der Regel leitet die
Lastverteilung eine TCPVerbindung (z. B. eine HTTPAnfrage) an einen speziellen
Server und lässt diese
Serverleitung bis zur Beendigung
der TCP-Session bestehen.
Partitionieren Sie die
Membership-Datenbank und
hosten jede Datenbankpartition
auf dedizierten SQL-Servern.
Vor dem Aufspielen von Daten
muss die MembershipDatenbank partitioniert werden.
Die partitionierten Datenbanken
können natürlich zuerst auf einer
Maschine verwaltet und erst
später auf dedizierten SQLServern angelegt werden. Wird
die Membership-Datenbank
schon vor der Partitionierung mit
Mitgliederdaten bevölkert,
müssen Sie mit einem
Migrationstool die partitionierte
Membership-Datenbank mit dem
Inhalt der aktuellen
Membership-Datenbank
repopularisieren.
In der DBStorage-Datenbank
werden Einkaufskorb, Aufträge
und Quittungen gespeichert. Die
DBStorage-Datenbank lässt sich
auch nicht so ohne weiteres
partitionieren. Minimale
Codeveränderungen (wie im
Abschnitt "Verbessern der
Architektur" beschrieben)
ermöglichen jedoch eine
Partitionierung und horizontale
Skalierung dieser Datenbank.
eingesetzt: IIS/ASPMehrfachserver, LDAPMehrfachserver, partitionierte
Membership-Datenbank-SQLServer, sowie ein Commerce
Store SQL-Datenbankserver.
Abbildung 2: Horizontale Hardwareskalierung
Die horizontale
Hardwareskalierung erhöht die
Kapazität der Serverfarm. Eine
weitere Skalierung erfordert
Verbesserungen an der
Systemarchitektur.
Verbessern der Systemarchitektur
Eine Verbesserung der
Systemarchitektur zur Erhöhung
der Effizienz der Serverfarm
erfordert die Konstruktion und
Bereitstellung der Applikation.
Grundsätzlich liegt das Ziel in der
Aufteilung der Arbeitsprozesse
gemäß deren Lastfaktoren, in der
Zuteilung von Servern zu jeder
Art von Belastung und in der
Leistungssteigerung jedes
Einzelnen. Dadurch können die
Server einfache Operationen
schneller ausführen und eine
größere Benutzerzahl pro Server
bedienen. Operationen mit
höheren Lastfaktoren, aber
geringeren Kapazitätsansprüchen
werden nur an einige wenige
Server vergeben.
Dedizierte Server bedienen
voluminösere Inhalte, wie z. B.
ASP-Inhalte, MTS und
BestellungspipelineKomponentenausführung. Auf
diese Art wird die gesamte
Serverbandbreite ohne
Beeinflussung der Wartung
statischer HTML/GIFInhaltsanfragen effizient
genutzt.
IIS beantwortet statische
HTML/GIF-Inhaltsanfragen
wesentlich schneller als ASPPage-Anfragen. So kann ein mit
der Bereitstellung von HTML/GIFInhalten beauftragter IIS-Server
10000 Benutzeranfragen
gleichzeitig abarbeiten, während
ein mit der Bedienung von
ASP/Commerce Pipeline
beschäftigter IIS-Server nur
1000 gleichzeitig erfolgende
Transaktionen bearbeiten kann.
Eine jüngst von Intel
durchgeführte Studie beweist,
dass alle Kundenzugriffe auf
Electronic-Commerce-Websites in
eine der fünf Kategorien fallen:
Browsen
Suchen
Anwenderregistrierung
Warenkorb füllen
Kaufen
Die Studie verdeutlicht, dass die
Anwender Browse-,
Registrierungs- und
Suchoperationen neunmal öfter
ausführen, als z. B. Operationen
wie "Ware in den Warenkorb
legen" oder "Kauf prüfen".
Anders ausgedrückt, bedeutet
das, dass von 100000 Benutzern
nur ungefähr 10000 den
Warenkorb füllen und kaufen,
aber 90000 Anwender browsen,
etwas suchen oder sich
registrieren lassen.
80%
9%
2%
5%
4%
Ungefähr 80 % des Verkehrs
werden von Servern bedient, die
statische Inhalte wie Browsen,
Anwenderregistrierung und
Suchoperationen ausführen
können; die verbleibenden 20 %
der anfallenden Transaktionen
und Anfragen erledigen spezielle,
für Hochlastbetrieb (Warenkorb
füllen und Kaufen) ausgelegte
Server. Da jedoch der
Hochlastbetrieb einhergeht mit
einer verringerten Anzahl von
Benutzerzugriffen, nimmt die
Zahl solcher Server ständig ab.
Dieses Schema lässt sich auf
einige Situationen anwenden, z.
B. statischen Inhalt (HTML/GIF),
dynamischen Inhalt
(ASP/Commerce-Pipeline),
Geschäftsvorschriften (MTSKomponenten), Plattendurchsatz
(cachen Sie alle aktiven Dateien)
und so weiter. Durch zusätzliche
architekturale Maßnahmen, die
im Folgenden aufgeführt sind,
lassen deutliche
Leistungssteigerungen bei
verbesserter Skalierbarkeit
erzielen:
 Abschalten des
IIS-SessionManagement
und Entfernen
der SessionVariablen
 Strikte
Trennung
statischer
Inhalte von
allen anderen
Inhalten
 Cachen von
statischen
Inhalten
 Cachen von
statischen
Suchanfragen
 Die gesamte
Geschäftslogik
wird auf
dedizierten
Servern
zusammengefa
sst
 Systemupdate
mit MSMQ oder
E-Mail






Batchverarbeit
ung von
Anfragen
Optimieren des
ASP-Codes
Optimieren der
Commerce
Pipeline
Optimierung
des
DatenbankSchemas
Optimierung
der
Katalogerstellu
ngs- und
Suchdienste
Optimierung
der SQLServerdatenba
nken
Abschalten der IIS-Sessionverwaltung und Entfernen von SessionVariablen
Vergewissern Sie sich, dass der
Applikationscode das IISSessionmanagement abschaltet
und keine Session-Variablen
verwendet werden. Die
Sessionsverwaltung von IIS
reserviert für jeden Anwender
einen ganz bestimmten
Speicherbereich, der dadurch
ständig vergrößert wird, dass die
Anwendung wegen der Zunahme
an Benutzerzugriffen ständig
neue Werte in die SessionVariable schreibt. Solange nur
wenige Werte in den SessionVariablen vorhanden sind, wird
die Leistung nicht merkbar
beeinflusst. Werden diese
Session-Variablen jedoch immer
umfangreicher (z. B. bei einem
Objektmodell) ist ein deutlicher
Leistungseinbruch nicht zu
verhindern.
Verbraucht die Session-Variable
zum Beispiel pro Benutzer 1 MB
Speicher, ergibt das bei 1000
gleichzeitig zugreifenden
Benutzern einen Speicherbedarf
von 1 GB. An diesem Beispiel
sieht man sehr schön, dass der
Gebrauch von Session-Variablen
bei einem vorhandenen
Speicherplatz von 1,5 GB in
Sachen Skalierbarkeit den
limitierenden Faktor darstellen.
Ohne diesen enormen
Ressourcenverbrauch könnten im
Rahmen der Verarbeitungsgrenze
der CPU eine ganze Menge mehr
Benutzer bedient werden.
Ein weiterer Nachteil von
Session-Variablen ist ihre
ausschließliche "Stationierung"
auf dem lokalen Server. Mit
anderen Worten, da die SessionVariable nur auf dem Server, der
sie gestartet hat gespeichert ist,
muss zwischen Client und diesem
Server eine Beziehung bestehen.
Um die unangenehmen
Nebeneffekte von "On-The-FlyRedundanz (egal, ob der Server
abstürzt oder heruntergefahren
werden muss, die Session ist zu
Ende) und dynamischem
Lastausgleich (verursacht
unbeständige Zugriffszeiten, d.
h. ein Benutzer verzeichnet sehr
lange Wartezeiten, bei einem
zweiten arbeitet das System
normal) zu vermeiden, setzt man
in diesem Fall den Befehl
"session stickiness" ein.
Die oben beschriebene Affinität
zwischen Client und Server wird
durch den Einsatz eines Cisco
LocalDirector-Routers
abgefedert, da dieser die QuellIP-Adresse verwendet, um die
Anfrage an einen Zielserver zu
heften. Verwendet der Client
jedoch zur Einwahl in das
Internet einen "load balanced"
Proxyserver, kann auch der
Cisco-Router wegen der
unterschiedlichen externen IPAdresse die "Session Stickiness"
nicht mehr weiter aufrecht
erhalten. Besonders
problematisch ist das Problem für
AOL-Kunden. Da AOL am
gesamten
Internetverkehrsaufkommen mit
ca. 25% beteiligt ist, wird dieses
Problem auch von den
entsprechenden SiteAdministratoren adressiert. Ein
beliebter Workaround ist der
Einsatz eines eigenen AOLServers zur kurzfristigen
Entlastung. Auf längere Sicht
wird ein einzelner dafür
abgestellter Server bei dem zu
erwartenden Wachstum von AOL
schlicht und ergreifend
"untergehen".
Soll für eine Benutzer-Session
der Status beibehalten werden,
empfiehlt sich als brauchbare
Alternative der Einsatz der
dynamischen Datenfunktion von
SSCE 3.0's LDAP-Dienst. Weitere
Informationen finden Sie unter
"Verwendung von MembershipVerzeichnis und Active User
Object (AUO) für SessionStatusdaten" des Site Server 3.0
Commerce Edition Resource
Kits.
Trennung von statischen und anderen Inhalten
Unter Bezugnahme auf die
erwähnte Intel-Studie werden in
den folgenden Tabellen die
beiden Verfahren zur
Bereitstellung eines
Zugriffsvolumens für 100000
gleichzeitig einwählende
Benutzer vorgestellt.
Verfahren 1: Nicht konsolidierte Serverfarm
Anzahl
der
Operation Inhaltsty Benutz
en
pen
er in
Prozen
t
Anzahl
der
Webser
ver
Anzahl
der
gleichzeit
ig auf
einen
Server
zugreifen
den
Benutzer
Browsen,
Suchen,
Anwenderregistrieru
ng, Ware
in den
Einkaufsko
rb, Kaufen
Alle
(statisch,
dynamisch 100%
, ASP,
etc.)
100
1,000
Gesamt:
Alle
100
nicht
100000
verfügbar
100%
Gesamtza
hl der
gleichzeiti
g
zugreifen
den
Benutzer
100000
Verfahren 2: Konsolidierte Serverfarm
Anzahl Anzahl
Operation Inhaltsty
der
der
en
pen
Benutz Webser
Anzahl
Gesamtza
der
hl der
gleichzeit gleichzeiti
er in
ver
Prozen
t
90%
g
zugreifen
den
Benutzer
9
ig auf
einen
Server
zugreifen
den
Benutzer
10000
10,000
Browsen
Ware in
den
Einkaufsko
rb, Kaufen,
Suchen,
Anwenderregistrieru
ng
Statisch
Andere
(dynamisc
10%
h, ASP,
etc.)
10
1,000
Gesamt:
Alle
19
nicht
100,000
verfügbar
100%
90000
Die Auswertung der Tabellen
zeigt einen Abfall der Front-EndServer von 100 auf nur 19, wenn
der statische Inhalt von den
anderen Inhaltstypen getrennt
wird.
Der Internet Information Server
(IIS) verarbeitet statische HTMLoder GIF-Inhalte sehr effizient,
die Bearbeitung ganzer ASPSeiten nimmt jedoch ziemlich
Prozessorzeit in Anspruch und
das geht auf Kosten der
Leistung. Zur optimalen
Auslastung dieser Server
kombiniert man am besten
Operationen mit gleichen oder
ähnlichen LastfaktorCharakteristika bzw.
Kapazitätsansprüchen und trennt
alle anderen davon. Nach
aktuellen Benchmarks kann ein
einzelner IIS-Server folgende
Benutzeranzahl gleichzeitig
bedienen:
Statische HTML/GIF-Inhaltsanfragen
Suchen - ASP-Seitenanfrage
Anwenderregistrierung - ASP-Anfrage
Ware in den Einkaufskorb - ASP-Anfragen
Kaufprüfung - ASP-Anfragen
Diese Zahlen verdeutlichen die
Notwendigkeit für den Einsatz
von drei verschiedenen Servern:
Einer zur Bearbeitung der
10,000 Benutzer
1,500 Benutzer
1,500 Benutzer
1,200 Benutzer
1,200 Benutzer
statischen HTML/GIF-Anfragen,
einer zum bearbeiten der ASPSuch- und
Anwenderregistrierungsanfragen
und der letzte zum bearbeiten
der Warenkorb und
Kaufprüfungs-ASP-Anfragen.
Überträgt man zum Beispiel die
vorstehenden Benchmarkzahlen,
die Prozentergebnisse der IntelStudie und legt 100000 Clients
zu Grunde, könnte die
Serverausstattung in etwa so
aussehen:
Statische HTML/GIFInhaltsserver
Suchen + Anwenderregistratur-ASP-Server
Ware in den
Warenkorb +
Kaufprüfungsserver
100,000 *
80%=
100,000 *
11%=
80,000 Users /
10,000 Users=
11,000 Users /
1,500 Users=
100,000 *
9%=
9,000 Users / 1,200
8 Server
Users=
Gesamtzahl der erforderlichen Frontend-Server:
(Die in der Tabelle präsentierten
Zahlen setzen die Trennung der
ASP-Produktseiten voraus, die
dann als statische HTML zur
Aufbauoptimierung umgesetzt
werden. Ganz so einfach, als dies
die Tabellenangaben vermuten
lassen, verhalten sich die Sites in
der Praxis doch nicht).
Cachen von statischen Inhalten
ASP-Seiten übersetzen die
mannigfaltigsten Skripts in HTML,
weder ganz dynamisch, noch
ganz statisch. Beispiele für
solche Daten sind
Produktattribute (Information,
Beschreibung, Preis usw.), SiteAnnouncements und
Verkaufsankündigungen.
Es gibt Verfahren, mit denen
man diese Informationen in
statische HTML-Seiten übersetzt
und als statischer HTML/GIFInhalt präsentiert werden. Durch
den Verzicht auf die ASPDatenbearbeitung und die
fehlende SQL-Server Anfrage
ergibt sich ein größerer
Durchsatz.
Ist zwar die Art der Information
ziemlich statisch, wird aber
8 Server
8 Server
24
Server
mancher Inhalt (z. B. der
Produktpreis) von einer
Datenbanktabelle (z. B. die
Preisermittlung durch ZIP-Code)
gesteuert, kombiniert man diese
Technik, indem man die
Produktinformation getrennt vom
Produktpreis in einem separaten
HTML-Rahmen ausgibt. Eine
andere Möglichkeit ist die
Verwendung eines ISAPI-Filters,
der HTML lesen kann und eine
Suche in einer Speicherbank
startet, so ähnlich, wie früher mit
.idc und .htx-Dateien die
Datenbankintegration vollzogen
wurde. Dieses Verfahren
vermeidet eine ASPDatenbearbeitung und
gewährleistet schnelle HTMLUmsetzung.
Cachen von statischen Look-Up-Daten
Sind Ihre Daten von
dynamischen Wertetabellen (z.
B. der Produktpreis abhängig
vom Zip-Code oder einer
Kunden-ID) oder von
Datenbanktabellen (wie die
Preisgestaltung mit Hilfe des ZIPCode) abhängig, verwenden Sie
zum Cachen der Wertetabelle
eine Speicherdatenbank, die Sie
nächtens (oder wenn
erforderlich) aus Gründen der
Datenaktualisierung auffrischen
können. Der, in Zusammenhang
mit der netzwerküberspannenden
Datenbeschaffung anfallende
Overhead entfällt.
Vielfach kann der in Echtzeit
vorhandene Inventarstatus, wie
z. B. die Anzahl der vorhandenen
Artikel, gegen eine "auf Lager"Flag ersetzt werden. Auch die
Look-Ups können im
Speichercache gehalten werden,
um nachts oder bei Bedarf
aktualisiert zuwerden. Ein, in
Zusammenhang mit der
Datenbeschaffung von einem
SQL-Server anfallende Overhead
entfällt. Eine Vorhaltung der
Daten im Speicher bringt ein
schnelleres Suchergebnis durch
verringerte Latenz (verursacht
durch die netzwerkumspannende
Datenbeschaffung) und
verbessert die Leistung.
Bei Anwendung dieses
Verfahrens sind kleine Tabellen
ideal. Durch Erhöhung der
Speicherkapazität können bei
Bedarf auch größere Tabellen
untergebracht werden. Eine
Analyse der IIS- und SQLServerlogs gibt Aufschluss
darüber, auf welche Tabellen
jüngst zugegriffen wurde und
welche Tabellen von einem Cache
am meisten profitieren würden.
Auf vielen Sites besteht der
Seiteninhalt aus einem HTMLListenfeld oder einer Combobox
(wie Produktkategorien oder
Produktabteilungen), die aus
einer Tabelle ermittelt wurden.
Es ist sinnvoll, diese Listen
einmal aufzunehmen und dann
das HTML-Fragment global im
ASP-Anwendungsobjekt zu
cachen, statt sie jedes Mal von
neuem mühsam holen zu
müssen. Daten cached man mit
dem Commerce Dictionary (gibt
es mit SSCE) oder dem MSDNDictionary-Object (wird von der
MSDN-Ressource gestellt).
Konsolidierte Geschäftslogik auf dedizierten Servern
Da Site Server 3.0 CPU-abhängig
ist, verbessert eine reduzierte
CPU-Nutzung die Leistung der
ASP-/Commerce PipelineVerarbeitung. Der CPU-Zugriff
wird durch Identifizierung und
Trennung von komplexen,
rechenintensiven Geschäftsregeln
(z. B. MTS-Komponenten) durch
spezielle Server vermindert.
Es gibt einen Trade-Off
hinsichtlich der Leistung
zwischen der Ausführung von
Komponenten innerhalb eines
Prozesses und einer Ausführung
der Komponenten außerhalb des
Prozesses über DCOM. Um den
exakten Wert des Trade-Offs zu
bestimmen, kann man die
Benchmarks beider Methoden
ermitteln, um dann die für die
eigene Site beste Methode zu
ermitteln.
Ist die Geschäftsregel sehr
rechenintensiv und sind die
Leistungskosten höher als die
Verwaltungskosten durch DCOM,
könnten Sie die Komponente als
MTS-Komponente entwickeln und
dafür einen extra Server zuteilen.
Dadurch wird wegen der
Durchsatzverbesserung auf der
ASP/Commerce Pipeline zugleich
deren Leistung verbessert.
Enthält die Geschäftsregel jedoch
nur einige Zeilen nicht sehr
rechenintensiven Codes, ist ein
dedizierter Server zur
Ausführung zu teuer. In diesem
Fall belassen Sie bitte den Code
als ASP-Funktionsschnippsel
(spart Objektaktivierungs- und
Invocationskosten) oder wenn es
sich bei dem Code um einen
komplizierten ASP-Code handelt,
kodiert man diesen mit Visual
C++/ATL als ASP COMKomponente und aktiviert ihn
örtlich (mit Hilfe des im ATLWizard enthaltenen ThreadingModells).
Systemupdate mit MSMQ oder E-Mail
Zum Updaten von Anforderung,
Data Warehouse, Berichte und
anderen Systemen verwenden
Sie statt einer
Datenbanktransaktion Microsoft
Message Queue Server (MSMQ)
oder E-Mail. MSMQ bzw. E-Mail
beeinflusst positiv die
asynchrone Kommunikation und
erzielt einen ziemlich guten
Transaktions- und
Operationsdurchsatz.
Zugriffsverzögerungen wegen
Datenbeschaffung oder
aufwendiger Berechnungen
werden vermieden.
Gibt beispielsweise eine Firma
(oder ein anderes Unternehmen)
die übliche Bestellanforderung
von einem geographisch anderen
Ort, als dem Standort des
Bestellungs-Empfängers ab (drop
ships), müssen beide Standorte
regelmäßig neue Bestellungen
und Versandbedingungen
miteinander austauschen. In
diesem Fall führt man keine
Datenbanktransaktion (z. B.
eine periodische Batch-Datei)
durch und sendet das Ergebnis
an die Remote Site, sondern
benutzt zum Versand von
Benachrichtigungen (z. B. neue
Bestellungen) die MSMQ-Dienste
oder E-Mail und erhält von der
Remote Site eine Bestätigung.
Die Frontend-Server akzeptieren
die Anfrage und leiten diese
geschwind weiter an MSMQ oder
zu einem E-Mail-Server, der die
Information an die Remote
Location übermittelt. Man erhält
dadurch eine schnellere
Verarbeitungsgeschwindigkeit
mit kürzerer Antwortzeit des
Frontend-Servers, d. h. die Sites
werden auf diese Weise schneller
aktualisiert.
Im allgemeinen erfordern die
meisten Sites unter bestimmten
Bedingungen die Anfertigung von
Berichten (zu Bestellungen,
Transaktionen, Gebrauch usw.)
Diese Berichte werden von den
Site-Administratoren als Kopien
von, auf der Hauptdatenbank
befindlichen Online-Logs oder
Datenbankprotokollen erstellt.
Mit MSMQ können solche Kopien
fast in Echtzeit auf einem zum
Empfang dieser Protokolle
berechtigten Server bereitgestellt
werden. Damit unterbindet man
elegant die sehr zeitraubenden
"Aufzeichnen-Kopieren"Datenbankoperationen. Die
Weiterverarbeitung der
Protokolle erfolgt fast in Echtzeit,
daher stehen an der Remote
Location ständig aktuelle Berichte
zur Verfügung. Die
Speicherkosten können nochmals
nach Erstellung der notwendigen
Berichte durch Ablegen der
weitergeleiteten und bereits
verarbeiteten Protokolle gesenkt
werden.
Statt eine In-LineDatenbanktransaktion
durchzuführen, können
Commerce Server-Bestellungen
und Quittungen asynchron
aufgezeichnet werden. Man
vermeidet damit
Transaktionsverzögerungen der
ASP-Seite, die die Informationen
schneller weiterverarbeiten kann.
Nachteilig an der Geschichte ist,
der Kunde erhält keine sofortige
Bestätigung seiner Bestellung,
sondern muss auf ein
bestätigendes E-Mail warten
(oder auf den Abschluss der
Bestell- und Belegtransaktionen
in Ihrer Datenbank). Die
asynchrone Aufzeichnung von
Commerce Server-Bestellungen
und Belegen empfiehlt sich
bestens für Sites mit ständigen
Lastspitzen.
Batch-Verarbeitung von Anfragen
Kreditkarten-, Steuer- und
ähnliche verarbeitungsintensive
Angelegenheiten werden am
besten im Batch-Modus auf
einem dedizierten Server
ausgeführt. Dadurch können
Frontend-Server auf Anfragen
wesentlich schneller mit höherer
Geschwindigkeit reagieren.
Ausfall- und Ausnahmeberichte
werden dem Käufer über E-Mail
zur Verfügung gestellt. Vielfach
existieren bereits LegacySysteme, die Batch-Verarbeitung
durchführen.
Optimieren des ASP-Codes
Vielfach werden Internet-Sites
auf "die Schnelle" entwickelt, d.
h. die Entwicklungsdauer ist
kurz, aber regelmäßig. Sehr oft
sind derartige "Entwicklungen"
auf einem unterentwickeltem
Code aufgebaut, dem es an
Effizienz, Klarheit und
Wiederverwendbarkeit fehlt.
Jeder dieser Faktoren beeinflusst
negativ die ASPCodeverarbeitung.
Zur Optimierung Ihres ASPCodes erstellen Sie ein einfaches
Utility, das den
Instrumentencode in Ihre ASPQuelltexte zum Aufzeichnen der
Ausführungszeit jeder Codezeile
einsetzt. Wird dann der ASPCode ausgeführt, erstellt dieser
ein sogenanntes
Quellenausführungsprofil, mit
dem jeder Quelltext, der einer
weiteren Optimierung bedarf,
identifiziert werden kann.
Manche Gruppierungen
behandeln Geschäftsbedingungen
als Commerce Pipeline-Skripte,
die nie kompiliert werden. Bei
jeder Skript-Komponente bemüht
der Commerce Server eine
Skript-Engine und das resultiert
in einer ständigen Aktivierung
und Anrufung mit
dementsprechendem Overhead.
Eine merkliche
Leistungssteigerung erhält man,
indem man
Geschäftsbedingungen in eine
Visual C++/ATL-kompilierte
Commerce-Pipeline- Komponente
konvertiert.
Optimierung der Commerce-Pipeline
Den Datendurchsatz der
Commerce Pipeline verbessert
man einerseits durch Entfernen
unnötiger Pipelinestufen,
andererseits unterteilt man die
Pipeline, wo möglich, in eine
eigene Ausführungsstufe und
vermeidet dadurch den
Aktivierungsoverhead und erhöht
die
Verarbeitungsgeschwindigkeit.
Natürlich kann die Pipeline
vollkommen umgangen werden,
es werden dafür angepasste
MTS-Komponenten verwendet.
Da man den Zugang zu ISVPipelinekomponenten
(Steuerkalkulation, Fracht,
Kreditkarten- Authorisierung)
von Drittherstellern verliert und
dadurch die Entwicklungskosten
rapide in die Höhe schnellen,
kann diese Maßnahme nicht
empfohlen werden.
Optimierung des Datenbank-Schemas
Die Optimierung des DatenbankSchemas geschieht durch völliges
Umgehen des Commerce-Shops;
man schreibt Warenkörbe,
Bestellungen und Belege direkt in
eine SQL-Serverdatenbank. Um
die DBStorage-Funktion zu
ersetzen, muss allerdings der
Code angepasst bzw. modifiziert
werden. Eigentlich umgeht man
mit diesem Verfahren die mit der
DBStorage-Funktion
einhergehenden
Zuordnungsfehler. Wie dem auch
sei, jedes zusätzliche Feld
erfordert eine Modifikation des
Datenbankschemas inklusive des
Read/Write-Codes zur
Unterbringung des neuen Felds.
Vielleicht sieht das alles sehr
einfach aus, erfordert jedoch ein
sorgfältiges Design, wobei ein
Benchmark des
Datenbankschemas zur
Überprüfung der maximalen
Leistungssteigerung nicht
Schaden kann.
Ein Nachteil in der Anwendung
dieser Technik liegt im Verlust
der Flexibilität des Commerce
Dictionary Object, sowie im
Zwang einer Modifizierung der
Datenbank, wenn dem
Warenkorb (orderform object)
ein neues Feld hinzugefügt wird.
Optimierung der Katalogerstellungs- und Suchdienste
Durch Trennen der statischen
von den dynamischen
Inhaltsanfragen und durch
Behandeln der verschiedenen
Anfragetypen auf einem
dedizierten Servern werden die
Katalogerstellungs- und
Suchdienste optimiert. In SSCE
3.0 sind die folgenden Dienste
integriert:
Katalogerstellungss Erstellt den Index-Katalog, der auf einem
erver
dedizierten Server ausgeführt wird.
Greift mit Suchanfragen auf den Katalog zu,
Suchserver
der auf einem dedizierten Server ausgeführt
wird.
Jede Instanz des
Katalogerstellungsdienstes kann
bis zu 32 Suchserver beinhalten;
zur Katalogerstellung und
Durchsuchung das optimale
Verfahren. Die Suchkapazität
kann durch Hinzufügen weiterer
Suchserver nochmals gesteigert
werden.
Optimierung der SQL-Serverdatenbanken
Microsoft® SQL Server™ 7.0
bietet gegenüber früheren
Versionen wesentliche
Verbesserungen, wie z. B.
automatisches Vergrößern,
verbesserte Leistung und die
Fähigkeit, Online-Backups
durchzuführen. Sie können von
SSCE 3.0 verwendete
Commerce-Shops, Ad Server und
Produktdatenbanken durch
Platzierung auf vertikal
skalierten, dedizierten High EndServern individuell erweitern.
Nimmt der Verkehr auf Ihrer Site
deutlich zu, sollten Sie folgende
Maßnahmen ergreifen:
 Weisen Sie der
Ad ServerDatenbank
mehrere SQLServer zu,
einen für jeden
Frontend-ASPServer, auf
dem Werbung
läuft. Planen
Sie die
Verwaltung der
KampagnenInformation,
das Sammeln
von Eindrücken
und
DurchklickErgebnissen.
 Weisen Sie
auch der
Produktdatenb
ank mehrere
SQL-Server zu.
Die Datenbanken des SSCE 3.0
Commerce Shops können auch
horizontal durch Partitionierung
mit dem Hash der Kunden-ID.
Dabei wird das Hash der KundenID zur Weiterleitung der
Datenbankoperationen (z. B.
Ware in den Einkaufskorb,
Bestellungen, Quittungen usw.)
an eine dedizierte CommerceShop-Datenbank eines
dedizierten High End-Servers
verwendet. Die letzten vier
Ziffern der Kunden-ID ordnen Sie
einem SQL-Server einer Gruppe
von Commerce-Shopverwaltenden SQL-Servern zu.
Das folgende Diagramm
verdeutlicht die
Strukturverbesserungen wie
dedizierte statische HTML/IISServer, dedizierte Such/Benutzerregistrations-ASPServer, dedizierte
Warenkorb/Kaufprüfungsserver,
parallele LDAP-Server, parallele
Membership-SQL-Server und
partitionierte Commerce-ShopDatenbanken auf parallelen SQLServern.
Abbildung 3: Architektonische Verbesserungen
Argumente gegen konsolidierte Webserver
Obwohl Sie Ihre Server
konsolidieren können, gibt es
Argumente, die gegen ein
solches Vorgehen sprechen. In
der Regel wird eine kommerzielle
Website mit hoher Kapazität,
starkem Verkehr und
Hochverfügbarkeit betrieben.
Stehen weniger Frontend-Server
zur Verfügung, bedeutet dies für
jeden einzelnen prozentual
anteilig eine höhere Belastung,
stärkeres Verkehrsaufkommen
und Verfügbarkeit. Folgende
Nachteile treten bei der
Konsolidierung einer WebserverFarm auf:
 Der Verlust
eines Servers
bedeutet einen
erheblich
höheren
Kapazitätsverlu
st als bei nicht
konsolidierten
Webservern.
 Eine
Kapazitätserhö
hung kann nur
in großen
Stufen
durchgeführt
werden.
 Die HardwareWartung ist
schwierig; die
Ausfallzeit
eines Servers
schwächt die
Leistung der
gesamten
Site.
 Die Redundanz
ist stark
begrenzt oder
kann nur mit
großem
Kostenaufwand
erreicht
werden.
 99.9%
Verfügbarkeit
ist beim
"Offline
nehmen"
großer
Kapazitätsblöc
ke kaum zu
gewährleisten.
Natürlich kann man die Nachteile
durch den Einsatz redundanter
Server, Festplatten, Netzteile
usw. etwas wettmachen. Wird
jedoch neue Hardware
hinzugefügt, sieht die Site in
Bälde wie eine unkonsolidierte
Webfarm aus.
Zusammenfassung
Man kann eine hochskalierbare
Site mit der geringstmöglichen
Anzahl von Servern durch
vertikale und horizontale
Skalierung und die
Implementierung struktureller
Verbesserungen aufbauen.
Werden die Server für das
Internet aufgesetzt, empfehlen
wir die horizontale Skalierung;
die dann redundanten Server
lassen eine vorausberechenbare,
abgestufte Kapazitätserhöhung
oder -minderung zu.
Das Konsolidieren von
Operationen gleicher
Belastungsfaktoren mit
dedizierten Servern ermöglicht
eine effiziente Ausstattung ihrer
Serverfarm mit der geringst
möglichen Anzahl von Servern.
Mit den in diesem Beitrag
beschriebenen Verfahren kann
SSCE 3.0 theoretisch so skaliert
werden, dass 88 Frontend-Server
100000 gleichzeitig zugreifende
Benutzer bedienen (die Zahlen
wurden auf einer Kunden-Site
durch Leistungstests ermittelt).
Skalieren Sie Backend-Server
nach Bedarf; die meisten Sites
bedürfen jedoch keiner
horizontalen Skalierung der
Backend-Server, da das gleiche
Resultat auch mit einer
vertikalen Serverskalierung
erzielt wird.
In Zukunft stehen Ihnen mit
Windows 2000, IIS 5 mit
Webclustern und anderen
Verfahren wie z. B. 1GHz Alphaund Merced-Prozessoren,
Windows 2000 64-bit weitere
aufregende Technologien zur
Skalierung, Leistungs- und
Kapazitätssteigerung Ihrer
Server zur Verfügung.
Die in diesen Unterlagen
enthaltenen Angaben und Daten,
einschließlich URLs und
Internetwebsites, können ohne
vorherige Ankündigung geändert
werden. Die BenutzerInnen
verwenden dieses Ressource Kit
auf eigene Verantwortung und
Risiko. Für dieses Ressource Kit
gibt es keine Unterstützung, es
wird so zur Verfügung gestellt,
wie es vorliegt, ohne
Garantieanspruch jeglicher Art,
weder ausdrücklich noch
unterstellt. Die Beispielfirmen,
Organisationen, Produkte,
Personen und Ereignisse sind frei
erfunden, soweit nichts anderes
angegeben ist. Jede Ähnlichkeit
mit echten Firmen,
Organisationen, Produkten,
Personen oder Ereignissen ist
unbeabsichtigt und rein zufällig.
Daraus kann keine
Schlussfolgerung, wie auch
immer, gezogen werden. Die
BenutzerInnen sind zum
Einhalten aller anwendbaren
Urheberrechtesgesetze
verpflichtet. Unabhängig von der
Anwendbarkeit der
entsprechenden
Urheberrechtsgesetze darf ohne
ausdrückliche schriftliche
Genehmigung der Microsoft
Corporation kein Teil dieser
Unterlagen für irgendwelche
Zwecke vervielfältigt oder
übertragen werden, unabhängig
davon, auf welche Art und Weise
oder mit welchen Mitteln,
elektronisch, mechanisch, per
Fotokopie, Aufnahme oder
ähnliches, dies geschieht.
Es ist möglich, dass Microsoft
Rechte an Patenten bzw.
angemeldeten Patenten, an
Marken, Urheberrechten oder
sonstigem geistigem Eigentum
besitzt, die sich auf den
fachlichen Inhalt dieses
Dokuments beziehen. Das
Bereitstellen dieses Dokuments
gibt Ihnen jedoch keinen
Anspruch auf diese Patente,
Marken, Urheberrechte oder auf
sonstiges geistiges Eigentum, es
sei denn, dies wird ausdrücklich
in den schriftlichen
Lizenzverträgen von Microsoft
eingeräumt.
 1999 Microsoft Corporation.
Alle Rechte vorbehalten.
Microsoft, Windows, Windows NT,
Microsoft SQL-Server und Visual
C++ sind entweder eingetragene
Warenzeichen oder Warenzeichen
der Microsoft Corporation in den
USA und/oder anderen Ländern.