HTTP Proxy Cache mit shared storage

Hallo,

ich bin auf der Suche nach einem HTTP Proxy Cache. Die Standardantwort ist hier ja eigentlich immer Squid (denke ich mal). Dummerweise wird Squid auf die zu puffernde Datenmenge vermutlich ueberhaupt nicht skalieren. Der Cache soll ungefaehr eine Groesse von 4 bis 8 TB haben und auch noch ein paar Millionen hits pro Stunde aushalten. (Nein, ich versuche damit keine koerperlichen Unzulaenglichkeiten zu kompensieren.)

Sowas erschlaegt man fuer gewoehnlich mit mehr Maschinen und einem Loadbalancer davor (oder einer Proxy-Hierarchie, wenn man sparen muss). Der Proxy-Phalanx wuerde man ein gemeinsames storage danebenstellen, damit nicht jeder einzelne Proxy die die Daten lokal halten muss.

Und genau hier ist Squid einfach nur doof, der moechte seinen Cache exklusiv fuer sich alleine haben. Ich seh aber gar nicht ein, fuer z.B. 8 Squids insgesammt 8TB x 8 = 64TB storage zu kaufen und dann auch noch damit zu leben, dass ein client mit irgendwas zwischen 7/8 = 87.5% und 1/8 = 12.5% auch noch erstmal einen miss erzeugt obwohl das Objekt schon in einem der Caches liegt und der trottelige Squid das Ding erstmal von einem seiner 7 Brueder ziehen muss. (Ich versteh ja auch nicht, was so kompliziert daran ist, eine URL auf eine eindeutige Postition im Dateisystem auf das Objekt selbst nebst Metadaten zu mappen.)

Jedenfalls: gibt’s da irgendwas, moeglichst frei und fuer Linux?

Danke im Voraus,
Gruss vom Frank.

Hallo Frank,

mir ist kein Produkt bekannt, das eine solche Konfigurations unterstüzt. Du sollst jedoch mit deiner Anfrage nicht im Regen stehen. Normalerweise nutzen die Proxy-Arrays nicht einen gemeinesamen Cache. Das Mappen ist hier nämlich nicht das Problem, sondern das Schreiben. Ein Proxy aus dem Array muss bei einem „Miss“ erstmal die Daten aus dem Internet laden und dann in den Cache speichern. Wenn jetzt ein zweiter Server aus dem Array auch seine Daten im Cache speichern will, würde es sehr schnell zu Inkonsitenzen kommen. Denn wenn zwei Speichern gewinnt üblicherweise der Letzte. Natürlich kann man ein solches Problem mit einer Dateisperre umgehen, dass würde aber dazu führen, dass ein Server auf einen Andern warten muss, bis dieser fertig mit Schreiben ist. Und warten ist heist immer Performanceeinbuse. Ein anderer Punkt ist die Ausfallsicherheit. Wenn der Cache korrupt wird, sind alle Server im Array betroffen und die Funktion der Proxys wäre mit einem Schlag aufgehoben. Um diese Unzulänglichkeiten zu verhindern, hat die Internet Engineering Task Force bereits 2001 ein paar Gedanken entwickelt. Dabei heraus kam das Cache Array Routing Protocol. Sinn der Sache ist dabei, das alle Proxys im einem Array einen eigenen Cache haben. Der Client entscheidet jedoch mit Hilfe des CARP an welchen Proxy er seine Anfrage sendet. Damit werden Redundanzen in den Caches vermieden. Es hat also nicht jeder Server den gleichen Inhalt in seinem Cache. Infos zu CARP findest du hier http://www.ietf.org/rfc/rfc3040.txt
Ich nutze zwar nicht Squid, jedoch ist im RFC Memo zu lesen, das Squid wohl CARP unterstüzt, du musst also dein Squid Array nur richtig konfigurieren. Dabei benötigst du nur (um bei deinem Beispiel zu bleiben) 1 TB pro Server, um die 8 TB Cache zur Verfügung zu haben.

Ich hoffe das hilft dir weiter
Gruss Micha