Turbo für den Tintenfisch

Neben kommerziellen Produkten hat sich der frei verfügbare Squid aufgrund seiner Flexibilität und Leistung einen Namen als Proxy gemacht. Seinen Ursprung hatte er im Harvest-Projekt [1], wo er als Objekt-Cache für das Index/Retrieval-System diente. Nach dessen Förderungsende 1996 übernahm Duane Wessels für das National Laboratory for Applied Network Research (NLANR) das Projekt und sorgte für die Weiterentwicklung. Derzeit liegt Squid in der Version 2.1PATCH1 vor.

Weit verbreitet sind die inzwischen nicht mehr offiziell unterstützten 1.1.x-Versionen mit 1.1.22 als letzter. Das liegt daran, daß sich Squids Cache-Format inzwischen geändert hat. Ein Versionswechsel bedeutet deshalb den Verlust aller Objekte im Cache, was nur eine langwierige Konvertierungsprozedur verhindern kann.

Eine Standardinstallation von Squid ist für geringe bis mittlere Anforderungen durchaus geeignet. Sind jedoch viele Anfragen zu verarbeiten oder brauchen die Proxy-Antworten zuviel Zeit, muß man Hard- und Software den gestiegenen Ansprüchen anpassen. Größte Auswirkung auf die Leistung eines Proxy-Caches haben die Netz- und Festplattenperformance. Der erste Schritt zur Optimierung der Squid-Standardinstallation besteht deshalb darin, die vorhandene Hardware und Betriebssystemsoftware im Hinblick auf diese Komponenten abzuklopfen.

Bei den Platten kommt es nicht vordringlich auf astronomische Transferraten an, denn die durchschnittliche Größe eines Objekts im Cache liegt bei etwa 12 KByte. Viel wichtiger ist, daß der Proxy zahlreiche Schreib- und Leseoperationen pro Sekunde durchführen kann. Denn bei gefülltem Cache werden laufend alte Objekte gelöscht, während neue hinzukommen. Die besten Werte lassen sich hier erreichen, wenn sich die Verzeichnisse des Proxy auf viele schnelle Festplatten verteilen, die an verschiedene SCSI-Adapter oder -Kanäle angeschlossen sind.

Möglichst viele schnelle Platten

Insbesondere bietet es sich an, mehrere Cache-Verzeichnisse zu verwenden und jedes auf eine eigene Festplatte zu legen. Ab Version 1.2.x lassen sich Platten unterschiedlicher Größe einsetzen, weil Squid seine Verzeichnisse unabhängig voneinander verwaltet. In der Datei squid.conf könnte das so aussehen wie in Listing 1.

# Cache Verzeichnisse
cache_dir /var/data/cache1 1849 16 64
cache_dir /var/data/cache2 1849 16 64
cache_dir /var/data/cache3 1849 16 64 
cache_dir /var/data/cache4 1849 16 64 
cache_dir /var/data/cache5 1849 16 64  
cache_dir /var/data/cache6 1849 16 64 
cache_dir /var/data/cache7 1849 16 64 
cache_dir /var/data/cache8 1849 16 64 
cache_dir /var/data/cache9 1849 16 64 
cache_dir /var/data/cache10 1960 16 64 
cache_dir /var/data/cache11 1960 16 64 
cache_dir /var/data/cache12 1960 16 64 
cache_dir /var/data/cache13 4022 16 64 
cache_dir /var/data/cache14 4022 16 64

Auch die Verzeichnisse für die Logdateien sollten auf verschiedenen Festplatten liegen. Für den normalen Betrieb reichen access.log und cache.log aus.

Weiterer Kandidat für eine Verlagerung auf eine eigene Festplatte ist das Verzeichnis, das die Metadaten für die einzelnen Cache-Verzeichnisse aufnimmt (Parameter cache_swap_log in squid.conf). Diese Logdatei ist das ‘Inhaltsverzeichnis’ der Cache-Verzeichnisse, das beim Programmstart gelesen wird. Für jedes Objekt im Cache enthält es einen Eintrag bestehend aus Nummer, Pfad zur Objektdatei, Zeitstempel, Expire- und Last-Modified-Header (falls vorhanden) sowie Größe und URL des Objekts.

Alternativ läßt sich auch mit Hilfe einer RAID-Konfiguration die Anzahl der Ein- und Ausgabeoperationen pro Sekunde erhöhen. Dabei dient beispielsweise ein auf mehrere Platten verteiltes Filesystem als Cache-Verzeichnis. Es ist allerdings umstritten, ob RAID eine bessere Performance als die Squid-Methode bietet. Jedenfalls ist die Ausfallsicherheit des Plattensystems beim Einsatz von RAID nur gewährleistet, wenn wenigstens die RAID-Level 0 und 1 (Striping und Mirroring) Anwendung finden. Dadurch steht dem Cache immer nur die Hälfte der vorhandenen Festplattenkapazität zur Verfügung, der Rest dient zur Spiegelung. Ohne sie geht beim Ausfall einer Platte gleichzeitig der gesamte Objekt-Cache verloren. Beim Squid-Verfahren ohne RAID verschwindet in diesem Fall nur ein Teil des Cache, das betroffene Verzeichnis kann aus der squid.conf ausgetragen werden, und der Proxy läuft weiter.

Genügend Speicher für Metadaten

Ist die Verzeichnisstruktur des Proxy optimal über die Platten verteilt, lohnt der Blick auf die RAM-Ausstattung. Für jedes Objekt im Cache fallen etwa 100 Byte Meta-Informationen im RAM an. Bei einer Cache-Größe von 40 GByte mit durchschnittlich 11 KByte großen Objekten und circa 3,6 Millionen Objekten im Cache sind allein 360 MByte RAM für die Verwaltung der Metadaten erforderlich. Diese Informationen dürfen nicht in den Swap ausgelagert werden, soll der Proxy benutzbar bleiben. Hinzu kommt der Platzbedarf von Objekten, die Squid im Arbeitsspeicher hält (Parameter cache_mem in squid.conf). Weiteren Speicher verbrauchen externe Squid-Programme (pinger, dnsserver, unlinkd) und natürlich andere aktive Programme sowie das Betriebssystem.

512 MByte Speicher sollten für stark frequentierte, große Proxies (mit mehreren Millionen Zugriffen pro Tag) vorhanden sein, im Idealfall läßt er sich noch ausbauen. Bei Neuinstallationen ist die genaue Beobachtung des Speicherverbrauchs unerläßlich. Insbesondere bei noch nicht gefülltem Objekt-Cache empfiehlt es sich, mit Hilfe von ulimit im Squid-Startskript den Speicherverbrauch zu begrenzen - sonst kann es passieren, daß der schöne neue Proxy-Rechner unbenutzbar wird, weil Squid den gesamten Hauptspeicher gefressen hat.

Nächster Ansatzpunkt für Optimierungsmaßnahmen ist das Betriebssystem des Proxy-Cache. Denn gleichgültig wie elegant die verschiedenen Cache-Verzeichnisse und Logfiles über die Festplatten verteilt sind, wenn das eingesetzte Filesystem wenig leistet, hat der Aufwand nicht viel Sinn gehabt.

Zunächst ist es zweckmäßig, alle Dateisysteme, für die hohe Last zu erwarten ist (also insbesondere die Cache- und Log-Verzeichnisse), so einzustellen, daß sie ihre Metadaten asynchron schreiben (sofern das nicht standardmäßig so ist). Das steigert zwar das Risiko des Datenverlustes bei einem Absturz der Maschine, da es sich in der Regel aber nicht um geschäftskritische Daten handelt, ist diese Maßnahme durchaus zu vertreten. Wichtiger sind die Verfügbarkeit des Proxy und kurze Antwortzeiten selbst unter hoher Last.

Schon bei der Installation läßt sich der Effekt dieser Maßnahme beobachten. Ein 133er Pentium unter Linux 2.0.35 legt die gesamte Cache-Verzeichnisstruktur etwa so schnell an wie eine UltraSPARC mit 167 MHz unter Solaris 2.6 das erste der 16 Cache-Unterverzeichnisse. Ursache: Linux’ ext2-Filesystem schreibt seine Metadaten standardmäßig asynchron, während das UFS von Solaris dies synchron erledigt.

Einen weiteren kleinen Geschwindigkeitsvorteil bringt die mount-Option noatime, die verhindert, daß der Zeitpunkt des Inode-Zugriffs bei jeder Operation aktualisiert wird. Damit bietet sie sich für die Filesysteme an, die Cache-Verzeichnisse enthalten.

Für Betriebssysteme, die diese Optionen von Haus aus nicht bieten (Solaris 7 soll verschiedene Verbesserungen in diesem Bereich bringen), gibt es unter Umständen andere Möglichkeiten. So lassen sich die UFS-Filesysteme älterer Solaris-Versionen mit dem Tool fastfs einzeln auf asynchrones Lesen und Schreiben der Metadaten umschalten.

Dies bringt zwar immer noch nicht die Performance, die ein ext2-Filesystem erreicht, ist aber besser als pures UFS. Squid kann seit Version 1.2.x ebenfalls asynchron schreiben, weil seitdem verschiedene Bereiche des Programms Threads nutzen. Dies läßt sich mit der configure-Option -enable-async-io aktivieren.

Kontrolle von newfs nötig

Im übrigen ist schon beim Anlegen eines UFS-Filesystems unter Solaris 2.6 erhöhte Aufmerksamkeit geboten. Offenbar ignoriert newfs in manchen Fällen die Standardwerte, die es benutzen sollte. Es lohnt also, einen Blick in die man-Page zu werfen und die Parameter -c und -C zu überprüfen, die die Fragmentierung des Dateisystems beeinflussen. Verwendet man newfs ohne weitere Optionen, wird es bereits bei 80 Prozent Füllung so fragmentiert sein, daß keine weiteren Objekte mehr darauf Platz finden. Mit

newfs -v -c 16 -C 7 -m 0 -o space\
/dev/rdsk/blafasel

ist man auf der sicheren Seite. Damit enthält jede Zylindergruppe 16 Zylinder, und das Dateisystem alloziert sieben zusammenhängende Blöcke für jede Datei - wie es standardmäßig vorgesehen ist.

Ein weiterer wichtiger Faktor für die Proxy-Leistung ist die Anzahl der Datei-Deskriptoren, die ein Prozeß öffnen darf. Bei nicht-modifiziertem Betriebssystem sind dies 1024 (Solaris 2.6) oder weniger (Linux 2.0.35/ libc5: 256). Für stark beschäftigte Proxy-Caches sind diese Werte zu klein, da im Normalbetrieb durchaus über 1500 Deskriptoren notwendig sind. Der Squid-FAQ ist zu entnehmen, wie sich für verschiedene Betriebssysteme die Standardwerte erhöhen lassen. Bei Solaris reicht ein Eintrag in /etc/system, für Linux 2.0.x ist ein Kernel-Patch erforderlich.

Einige Implementierungen von select() können nur 1024 FileDeskriptoren verwalten. Wer für größere Anforderungen gerüstet sein will, muß beim Squid-Übersetzen die configure-Option -enable-poll wählen. Bei älteren Versionen ist dazu nach dem configure-Lauf die entsprechende Option im Makefile auszukommentieren. Dadurch benutzt das Programm poll() statt select().

Ein letzter Ansatzpunkt für Optimierungen im Betriebssystembereich ist die malloc-Bibliothek. Manche Varianten sind auf Squids Anforderungen nicht optimal ausgelegt: Sie geben allozierten und wieder freigegebenen Speicher möglicherweise nicht komplett an das Betriebssystem zurück. Dies äußert sich darin, daß der Squid-Prozeß weiter wächst, obwohl der Objekt-Cache schon komplett gefüllt ist. Eine malloc-Bibliothek, die sich für den Einsatz mit Squid gut eignet, ist Doug Leas DL-malloc. Sie ist inzwischen im Lieferumfang enthalten und mit der configure-Option -enable-dlmalloc aktivierbar.

Einige Übersetzungsoptionen verbessern die Leistung von Squid bei hoher Last. Dazu gehören -enable-icmp, -enable-forw-via-db und -enable-cache-digests, wenn der Proxy Teil einer Cache-Hierarchie oder eines Cache-Clusters ist. Sie stellen ihm verschiedene Werkzeuge zur Verfügung, mit denen er die schnellste Quelle innerhalb der Hierarchie für ein Objekt ermitteln kann. -enable-carp bewirkt, daß Squid sich auch mit dem Microsoft-Proxy verständigen kann.

Parameter für individuelle Erfordernisse

Neben den verschiedenen Schaltern zur Übersetzung des Source-Paketes beeinflussen viele Einträge in squid.conf die Leistung. Grundsätzlich müssen die Einstellungen dort individuell auf die jeweilige Situation abgestimmt werden. Parameter, die mit Sicherheit eine Rolle spielen, wenn es um eine Leistungssteigerung von Proxies geht, sind

• Refresh-Patterns: wie lange bleiben welche Objekte im Cache;
• der Quick-Abort-Parameter: lädt der Proxy ein Objekt vollständig, obwohl der Client die Verbindung bereits getrennt hat;
• die Maximalgröße für aufzunehmende Objekte.

Das heißt nicht, daß diese Parameter unbedingt zu ändern sind, um einen ‘schnellen’ Proxy aufzubauen (im Gegenteil: die Standardeinstellungen sind vernünftig gewählt). Es lohnt sich jedoch trotzdem, ihre Werte zu prüfen und gegebenenfalls anzupassen.

Zu einem Hemmschuh für Proxies mit hohem Durchsatz kann sich eine schlechte DNS-Performance entwickeln. Um URLs aufzulösen, verwendet Squid seine externen dnsserver-Prozesse. Der DNS-Lookup ist ein ‘blocking call’ - das heißt, wenn alle dnsserver auf Antwort vom Nameserver warten, kann der Proxy in dieser Zeit weitere Anfragen zwar annehmen, aber nicht mehr ausführen. Der squid.conf-Parameter dns_children regelt die Anzahl von dnsserver-Prozessen.

Es empfiehlt sich, mit dem Cache-Manager regelmäßig den Status des IP-Cache und der dnsserver abzufragen und im Zweifelsfall so viele zu starten, daß wenigstens einer ständig untätig ist. Bei vielbeschäftigten Proxies können durchaus zehn und mehr Prozesse nötig sein.

Noch weiter verbessern läßt sich die DNS-Leistung, indem man auf dem Proxy-Rechner einen Cache-only-DNS-Server installiert, den Squids dnsserver als erstes befragen. Weiterhin lohnt sich für mehrere Caches innerhalb eines Clusters oder einer Hierarchie die Einrichtung eines Nameservers, den alle lokal installierten DNS-Server als ‘forwarder’ befragen. Auf diese Weise läßt sich die durchschnittliche DNS-Abfragezeit auf wenige Millisekunden senken.

Mehr Treffer durch Cache-Hierarchien

Zwar sind alle bisher geschilderten Maßnahmen für einzelne Proxies anwendbar, es ist aber offensichtlich, daß der geschickte Aufbau einer Cache-Hierarchie eine bessere Trefferrate erzielt als ein einzelner Proxy-Cache. Beispielsweise ist es möglich, drei Maschinen unter demselben Namen als Proxy für die Benutzer einzusetzen und so zu konfigurieren, daß sie Anfragen, die sie nicht aus ihrem Cache beantworten können, an zwei weitere schicken, die als ‘parent’ für sie fungieren.

Dabei sorgt DNS-Round-Robin für eine nahezu gleichmäßige Lastverteilung auf die ersten drei Maschinen. Benutzt man zusätzlich einen dynamischen DNS-Server oder ein Konzept für IP-Failover, so daß beim Ausfall einer Maschine automatisch eine andere deren IP-Adresse übernimmt, ist der Proxy-Dienst - außer bei Leitungsausfällen - immer verfügbar. Gleichzeitig erhöht sich durch die Staffelung der Maschinen die Trefferrate.

Unabhängig von der Verbindung der Caches miteinander ist immer darauf zu achten, daß bei der internen Kommunikation keine Engpässe auftreten. Die günstigste Verbindung in einem Cache-Cluster stellt die Verwendung von Multiport-Ethernet-Karten (100Base-T) dar, wobei die Anbindung direkt, ‘full-duplex/back-to-back’ erfolgt. Eine Alternative ist die Verbindung der einzelnen Caches über einen eigenen Switch, der hinreichend leistungsfähig sein muß.

Nach Inbetriebnahme eines Proxy ist eine ständige Kontrolle der Performance angebracht, um bei Problemen sofort reagieren zu können. Für die älteren Squid-Versionen empfiehlt sich dafür der Timer-Patch. Mit ihm lassen sich leicht Engpässe im Squid-Betrieb ermitteln. Für Anwender aktuellerer Versionen ist calamaris das Werkzeug der Wahl.

Änderungen von System- und Leistungsdaten des Proxy lassen sich mit mrtg permanent erfassen und grafisch im Web darstellen. Wie das genau funktioniert, kann man hier lernen.

Obwohl Squid schon heute eine sehr leistungsfähige Cache-Software ist, bleibt noch viel zu tun. Insbesondere bei den Auswahl-Algorithmen für die schnellste Quelle eines Objektes innerhalb einer Cache-Hierarchie gibt es immer wieder neue Entwicklungen und Ideen. Dasselbe gilt für den Aufbau transparenter Proxies, die den gesamten Verkehr großer Universitäten oder Firmen verarbeiten müssen. Auch als Beschleuniger für Sites mit dynamischen Anteilen und hohen Abfragezahlen findet Squid Beschäftigung.

TÖNS BÜKER
arbeitet bei der Telemedia GmbH & Co. KG im Team System Development und befaßt sich dort mit Internet-Diensten aller Art sowie der Unix-Systemadministration.

Literatur

[1] Oliver Schade; Gemeinsam sind wir schneller; Hierarchischer Cache-Verbund mit Harvet

[2] Rainer Klute; Zwischenstation; Mit dem Proxy-Server Zeit und Geld sparen; iX 2/95, S. 154 ff.

(ck)